fix(ai): #850 follow-ups — target-dir event, one Ollama reader for any host, no gemini fallback - #852

Description

These are follow-ups to #850, found by the forge_docs review of #850 (Agenticstiger/forge_docs#204) and by two reviews of this diff. There is one commit per fix.

1. fix(forge): --agent reports a contract written to a --target-dir outside the cwd.
   • The receipt and the forge.contract_written event came from a snapshot of the cwd only, two levels deep. A target outside it, or deeper, got neither.
   • The stated target is now snapshotted too, with ~ expanded as the writer expands it. A file outside the cwd is reported by its absolute path.
2. fix(ai): one Ollama address for every read, any host, from the stated endpoint.
   • OLLAMA_HOST was read four ways. The chat call dialled any host. Detection, the default-model pick and fluid ai setup ignored a non-local host and asked localhost, so the model came from one daemon and the call went to another.
   • fluid_build/llm/ollama_host.py is now the single reader. It follows ollama-python's _parse_host convention (MIT).
   • A stated endpoint now drives the model pick, the model preflight and the fluid ai test model check. A --tiered stage keeps it too.
   • Credentials in the address: they are sent as basic auth; fluid doctor and fluid ai setup show them masked; ai_config.json doesn't store them unless FLUID_ALLOW_PLAINTEXT_AI_SECRETS is set; and the environment's OLLAMA_HOST wins over the saved host.
3. fix(ai): stop with copilot_no_llm_provider instead of guessing gemini.
   • With nothing selecting a provider, forge used gemini. It sent FLUID_LLM_API_KEY to Google whatever key it was, and with two provider keys set it asked for a gemini key.
   • It now stops with the reason, in the same words fluid doctor shows.

Two owner decisions (2026-11-12) set the behaviour:

• OLLAMA_HOST may name any machine, as ollama-python allows. It is already a protected name that a project .env cannot set.
• There is no silent provider fallback.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would break existing functionality)
  • A run whose only setting is FLUID_LLM_API_KEY now stops instead of using gemini.
  • fluid ai test --endpoint and fluid ai setup accept a non-local Ollama.
  • LlmProvider.list_available_models takes an endpoint keyword. It is passed only when an endpoint is stated, so a two-argument plugin keeps working until then.
• Documentation update
• Refactor / code cleanup
• New provider or provider enhancement

Documentation

• Docs PR linked:
  • Docs PR: docs(ai): no gemini fallback, one Ollama address for every read, --agent target dirs (forge-cli#852) forge_docs#205 (draft, 10 pages; its markers switch to the main form when this merges)
• No docs needed — this change does not affect user-facing behaviour
• Docs TODO — I know docs are needed and will create a PR in forge_docs before this is merged

Checklist

• I have read the Contributing Guide
• My code follows the project's coding standards
• I have added tests that prove my fix/feature works
• All new and existing tests pass (pytest)
• I have run ruff check and black with no errors
• New maintained Python files include license headers (python scripts/add_license_headers.py; examples/** exempt)

Testing

Live A/B runs through the fluid CLI, against main at 28a1f2e:

• The runs were isolated from the machine's own setup: temp HOME, null keyring backend, and HTTP_PROXY pointed at a dead port to hide the local Ollama. A stub Ollama daemon served the remote-host checks.
• fluid forge --agent --llm-provider ollama --llm-model qwen3-coder:30b -d <outside cwd>
  • main: no forge.contract_written and no forge-receipt.json.
  • This branch: forge.contract_written with the absolute path, action: created, and the receipt written.
• fluid ai test --provider ollama --endpoint http://127.0.0.1:11434, with OLLAMA_HOST set to a stub that lacks the model
  • main: exit 4, "model ... was not returned by the provider".
  • This branch: model available, FLUID_OK, exit 0.
• fluid forge with OLLAMA_HOST on a LAN-IP stub and no --llm-model
  • main: "OLLAMA_HOST points to a non-localhost address (...), ignoring". It picked gemma4:31b from the local daemon while the chat went to the stub.
  • This branch: no warning, and the model and the chat both come from the stub.
• fluid forge with OPENAI_API_KEY and ANTHROPIC_API_KEY set and nothing else
  • main: "No API key was configured for the gemini copilot adapter".
  • This branch: names both keys and asks for --llm-provider. fluid doctor shows the same message.

Tests:

• New: tests/test_ollama_host.py, tests/test_llm_no_provider.py, and 4 tests in tests/cli/test_forge_agent_mode.py. A verifier ran them against main: they fail there and pass here.
• The 63 related test files, tests/copilot and the startup budget give 3442 passed. Commits 1 and 2 are each green on their own, at 3380 and 3422 passed.
• Full suite locally: 34485 passed. The 9 failures and 2 collection errors fail identically on main in the shared venv (dlt version drift, missing bashlex, the lazy-core and duckdb-sandbox baseline), or are load-sensitive and pass when run alone.
• fluid --help startup budget: 301 modules, the same as main.

Reviews:

• A Sonnet verifier ran twice.
• An Opus security review found no new egress path and no non-operator control of the Ollama address. Its 3 credential findings (plaintext save, terminal print, username-only token) are fixed here.

Command Center is unaffected. It always passes --llm-provider with a matching key, never sets OLLAMA_HOST, and has no LlmProvider subclass.

Not in this PR

• FLUID_LLM_API_KEY can still reach a provider forge only inferred, such as an ambient Ollama or a keyring-inferred provider. This is older than this change, and its rule needs an owner decision.
• Non-interactive runs still don't read the saved fluid ai setup choice. The new message names the saved provider and the flag to pass.